Today's enterprises often deploy mission-critical databases that can comprise several hundred gigabytes, and often several terabytes of data. The support and maintenance requirements of such very large databases (VLDBs) can be challenging. Certain strategies for managing VLDBs include database object partitioning. Partitioning addresses size and other issues for supporting very large tables and/or indexes of VLDBs. Partitioning decomposes large tables into more manageable (e.g., smaller) pieces (e.g., partitions).
When using partitions, queries and/or data manipulation language (DML) statements can access partitioned tables and/or partitioned indexes as if referring to the non-partitioned table. On an ongoing basis, data definition language (DDL) statements can access and/or manipulate individual partitions rather than having to manipulate entire tables and/or indexes. Such partitioning offers several advantages to users of VLDBs. For example, the latency for certain operations (e.g., data loads, index creation, etc.) and/or queries can be significantly reduced since such operations and/or queries operate over the smaller sets of partitioned data and/or respective indexes. Other benefits might also be enabled by partitioning, such as enhanced availability of mission-critical databases, increased resource utilization, and/or other benefits. In some cases, partitioning might entail moving one or more data tables from one physical storage location to another physical storage location in a distributed storage environment so as to improve access performance and/or storage resource utilization.
Unfortunately, legacy techniques for creating partitioned data tables and/or indexes can introduce unwanted downtime or other DML, access blocking. Specifically, certain legacy approaches might lock out DML accesses during partitioning or movement of an initial state database space to an altered (e.g., partitioned or moved) state. In legacy situations such a downtime period or blocking period might become long. In some legacy cases, the downtime period or blocking period becomes very long, at least inasmuch as the totality of partitioning operations (e.g., partition a non-partitioned table, repartition a partitioned data table, move a partitioned table to another physical storage location, regenerate respective new instances of index tables and/or auxiliary attribute tables, regenerate affected constraints, triggers, etc.) often demands a significant amount of processing power and processing time.
Some legacy approaches require explicit synchronization operations (e.g., lockout operations) to be observed when partitioning. For example, during an alteration period, users might be prohibited from accessing either the original subject table or the partitioned tables during the entirety of the period. Further, some legacy approaches require the user to determine the partitioning strategy and/or construct the multiple DDL statements for executing the partitioning strategy.
What is needed is a technique or techniques to improve over legacy and/or over other considered approaches. Some of the approaches described in this background section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.